Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: PotentialFrame is parametric #377

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

nstarman
Copy link
Contributor

@nstarman nstarman commented Jul 4, 2024

This PR makes PotentialFrame parametric wrt to the potential type.

Copy link

codecov bot commented Sep 19, 2024

Codecov Report

Attention: Patch coverage is 80.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 80.09%. Comparing base (2f7359e) to head (c0b126a).

Files with missing lines Patch % Lines
src/galax/_interop/galax_interop_gala/potential.py 0.00% 3 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (2f7359e) and HEAD (c0b126a). Click for more details.

HEAD has 1 upload less than BASE
Flag BASE (2f7359e) HEAD (c0b126a)
7 6
Additional details and impacted files
@@             Coverage Diff             @@
##             main     #377       +/-   ##
===========================================
- Coverage   96.59%   80.09%   -16.50%     
===========================================
  Files          76       76               
  Lines        3028     3035        +7     
===========================================
- Hits         2925     2431      -494     
- Misses        103      604      +501     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@nstarman
Copy link
Contributor Author

nstarman commented Sep 19, 2024

@wesselb I'm encountering an interesting Plum issue here. I would expect Plum to be able to grok this return type. Any insight would be greatly appreciated :)
Is the problem with Generics?

@wesselb
Copy link

wesselb commented Sep 23, 2024

Hey @nstarman! I think the problem is indeed with generics. If I'm not mistaken, this reproduces the issue:

In [8]: from typing import Generic, TypeVar

In [9]: T = TypeVar("T")

In [10]: class A(Generic[T]):
    ...:     pass
    ...:

In [11]: resolve_type_hint(A)
Out[11]: __main__.A

In [12]: resolve_type_hint(A[int])
<ipython-input-12-9cf80670f4aa>:1: UserWarning: Could not resolve the type hint of `__main__.A[int]`. I have ended the resolution here to not make your code break, but some types might not be working correctly. Please open an issue at https://github.com/wesselb/plum.
  resolve_type_hint(A[int])
Out[12]: __main__.A[int]

It should fortunately be fairly easy to fix this. This if-statement should be extended to detect generics and recurse into the type parameters of the generic. This SO answer suggests that checking for the attribute __origin__, and the attribute __args__ can be used to get the parameters.

I don't quite have the time to fix this now (sorry :( ), but could possibly at the end of this week or the beginning of next week!

EDIT: I should add that Plum doesn't support typing.Generic at all, mostly because you cannot construct instances of generics, i.e. type(A[int]()) is A.

@nstarman
Copy link
Contributor Author

Thanks @wesselb for investigating the issue!
Before I start addressing this, re your comment edit do you envision plum supporting Generics?
Also, does https://github.com/beartype/beartype/releases/tag/v0.19.0 help (e.g. the Use Case 3: Multiple Dispatch).
Should I open a PR for This if-statement ?

@wesselb
Copy link

wesselb commented Sep 29, 2024

Before I start addressing this, re your comment edit do you envision plum supporting Generics?

Ah, I replied without thinking this through too carefully. Plum currently does not support generics, but it could certainly support them in the future. The fact that you cannot construct instances is unimportant! There are two ways to support generics: (1) if beartype at some point supports them, Plum will support them too; and (2) we could implement support for generics without support by beartype.

I think an incomplete implementation supporting commonly used patterns of generics should actually be feasible, although technical.

Should I open a PR for This if-statement ?

If you could, then that would be amazing. :) This should solve the warning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants